1. Field of the Invention
The present invention relates generally to a broadband wireless access communication system, and more particularly to a system and method for controlling operation states of a medium access control layer.
2. Description of the Related Art
In a 4th generation (4G) communication system, which is the next generation communication system, research is being performed to provide users with services having various qualities of service (QoSs) at a high transmission speed.
A wireless local area network (LAN) communication system and a wireless metropolitan area network (MAN) communication system generally support transmission speeds of 20 to 50 Mbps. Because the wireless MAN communication system has wide service coverage and supports a high transmission speed, it is suitable for supporting a high-speed communication service. However, the wireless MAN system does not in any way reflect the mobility of a user, i.e., a subscriber station (SS), nor does it reflect in any way a handover according to the high-speed movement of the SS.
Accordingly, in a current 4G communication system, a new type of communication system ensuring mobility and QoS for the wireless LAN system and the wireless MAN system supporting relatively high transmission speeds is currently being developed to support a high speed service to be provided by the 4G communication system.
An IEEE (Institute of Electrical and Electronics Engineers) 802.16a communication system is a system utilizing an Orthogonal Frequency Division Multiplexing (OFDM) scheme and an Orthogonal Frequency Division Multiple Access (OFDMA) scheme in order to support a broadband transmission network for a physical channel of the wireless MAN system.
The IEEE 802.16a communication system considers only a single cell structure and stationary SSs, which means the system does not in any way reflect mobility of the SSs at all. However, An IEEE 802.16e communication system has been defined as a system reflecting mobility of an SS in addition to the IEEE 802.16a communication system, thus should reflect mobility of an SS in a multi-cell environment.
In order to provide the mobility of an SS in a multi-cell environment as described above, it is inevitably required that change of operation states of the SS and a base station (BS) is possible. Therefore, research concerning the handover of the SS in consideration of the multi-cell structure is now actively being performed in order to support the mobility of the SS. Herein, an SS having the mobility is referred to as an MSS (mobile subscriber station).
FIG. 1 is a block diagram schematically illustrating a conventional IEEE 802.16e communication system. Referring to FIG. 1, the IEEE 802.16e communication system has a multi-cell structure, that is, a cell 100 and a cell 150. Also, the IEEE 802.16e communication system includes a BS 110 for controlling the cell 100, a BS 140 for controlling the cell 150, and a plurality of MSSs 111, 113, 130, 151, and 153. The transmission/reception of signals between the BSs 110 and 140 and the MSSs 111, 113, 130, 151, and 153 is accomplished using an OFDM/OFDMA method. The MSS 130 is located in a cell boundary area (i.e., handover area) between the cell 100 and the cell 150. Accordingly, it is possible to support the mobility for the MSS 130, only when a handover for the MSS 130 is supported.
In the IEEE 802.16e communication system, a certain MSS receives pilot channel signals transmitted from a plurality of BSs and measures Carrier to Interference and Noise Ratios (CINRs) of the received pilot channels. The MSS selects a BS transmitting a pilot channel signal having the highest CINR from among the measured CINRs as a serving BS, which is a BS to which the MSS currently belongs. That is, the MSS identifies a BS transmitting the best pilot channel signal that the MSS can receive in the best condition from among the BSs as the serving BS to which the MSS currently belongs. After selecting the serving BS, the MSS receives the downlink frame and uplink frame transmitted from the serving BS and uses them in transmitting and receiving data.
When the mobility of subscriber station is taken into consideration in the IEEE 802.16e communication system as described above, power consumption of the MSS plays an important part in the performance of the entire system. Therefore, a sleep mode or state operation and an awake mode or state operation corresponding to the sleep state operation have been proposed for the BS and the MSS in order to minimize the power consumption of the MSS.
FIG. 2 is a state diagram schematically illustrating the operation states supported by a Medium Access Control (MAC) layer of the IEEE 802.16e communication system. Referring to FIG. 2, the MAC layer of the IEEE 802.16e communication system supports two kinds of operation states, i.e., an awake state 210 and a sleep state 220. The sleep state 220 has been proposed to minimize the power consumption of the MSS during the idle interval in which the packet data is not being transmitted. That is, the MSS state-transits (211) from the awake state 210 into the sleep state 220, thereby minimizing the power consumption of the MSS during the idle interval in which the packet data is not being transmitted.
In general, the packet data is transmitted in a burst when generated. Accordingly, it is unreasonable that the same operation is performed in both an interval in which packet data is not transmitted and an interval in which packet data is transmitted. Therefore, the sleep state operation as described above has been proposed.
However, when packet data to be transmitted is generated while the MSS is in the sleep state, the MSS state-transitions to the awake state and transmits/receives the packet data. However, because the packet data is highly reliable on a traffic mode, the sleep state operation must be organically performed in consideration of the traffic characteristic and the transmission scheme characteristic of the packet data, i.e., the sleep state operation must be performed by considering the traffic characteristic and the transmission scheme characteristic of the packet data in the awake state.
In order to state-transition into the sleep state 220, an MSS must necessarily receive state transition consent from a BS. Further, the BS must enable the MSS to shift into the sleep state 220 while simultaneously buffering or dropping the packet data to be transmitted to the MSS. Also, the BS must inform the MSS of existence of packet data to be transmitted during the listening interval of the MSS. Herein, the MSS awakes from the sleep state 220 and checks if there exist packet data to be transmitted from the BS to the MSS. The listening interval will be described below in more detail.
When there is packet data to be transmitted from the BS to the MSS, the MSS state-transitions to the awake state 210 from the sleep state 220 and receives the packet data from the BS. However, when there is no packet data to be transmitted from the BS to the MSS, the MSS remains in the awake state 220.
Hereinafter, parameters required for operating in the sleep state and the awake state will be described.
1) A Sleep Interval
The sleep interval is requested by an MSS and assigned by a BS according to the request of the MSS. The sleep interval represents a time interval from a state-transition of the MSS into the sleep state 220 to a state-transition of the MSS into the awake state 210 again. That is, the sleep interval is an interval in which the MSS stays in the sleep state 220. The MSS may continue to stay in the sleep state 220 even after the sleep interval is over. In this case, the MSS updates the sleep interval by performing a sleep interval update algorithm using a preset initial sleep window value and a final sleep window value. Herein, the initial sleep window value corresponds to a minimum sleep window value and the final sleep window value corresponds to a maximum sleep window value. Further, the initial sleep window value and the final sleep window value are assigned by all BSs and expressed by the number of frames. Because the minimum window value and the maximum window will be described in detail below, a further description is omitted here.
2) A Listening Interval
The listening interval is requested by an MSS and assigned by a BS according to the request of the MSS. Further, the listening interval represents a time interval from a time point at which the MSS is awaken from the sleep state 220 to a time point at which the MSS synchronizes with the downlink signal of the BS in order to be capable of decoding downlink messages such as a traffic indication (TRF_IND) message. Herein, the traffic indication message is a message representing existence of traffic (i.e., packet data) to be transmitted to the MSS. Because the traffic indication message will be described below in more detail, a detailed description is omitted here. The MSS determines whether to stay in the awake state or to state-transition into the sleep state again according to the values of the traffic indication message.
3) A Sleep Interval Update Algorithm
When the MSS state-transitions into the sleep state 220, it determines a sleep interval while considering a preset minimum window value as a minimum sleep state interval. After the sleep interval passes, the MSS is awaken from the sleep state 220 for the listening interval and checks if there is packet data to be transmitted from the BS. I
If there exist no packet data to be transmitted, the MSS renews the sleep interval to be twice as long as that of a previous sleep interval and remains in the sleep state 220. For example, when the minimum window value is “2”, the MSS sets the sleep interval to be 2 frames and stays in the sleep state for 2 frames. After passage of the 2 frames, the MSS awakes from the sleep state and determines if the traffic indication message has been received.
When the traffic indication message has not been received (that is, when no packet data transmitted from the BS to the MSS exists), the MSS sets the sleep interval to be 4 frames (i.e., twice as many as 2 frames) and remains in the sleep state 220 during the 4 frames. Also, when the MSS detects an absence of data targeting the MSS from the traffic indication message, even though the MSS has received the traffic indication message, the MSS sets the sleep interval to be 4 frames (twice as many as 2 frames) and remains in the sleep state 220 during the 4 frames. The operation of detecting the absence of data targeting the MSS from the traffic indication message will be described in more detail later and is thus omitted here. The sleep interval increases within a range from the initial sleep window value to the final sleep window value.
Hereinafter, messages currently defined in the IEEE 802.16e communication system for supporting operations in the sleep state 220 and the awake state 210 as described above, will be described.
1) A Sleep Request (SLP REQ) Message
The sleep request message is transmitted from an MSS to a BS and is used when the MSS requests a state-transition to the sleep state 220. The sleep request message contains parameters, i.e., information elements (IEs), required when the MSS operates in the sleep state 220. Table 1 shows the format of the sleep request message.
TABLE 1SyntaxSizeSLP-REQ_Message_Format(| {  Management Message Type = 45 8 bits  Initial-sleep window 6 bits  Final-sleep window10 bits}
The sleep request message is a dedicated message transmitted based on a connection ID (CID) of an MSS. The information elements of the sleep request message shown in Table 1 will be described hereinafter.
The ‘Management Message Type’ represents a type of a message currently being transmitted. For example, when the ‘Management Message Type’ has a value of 45 (Management Message Type=45), it represents the sleep request message. The ‘Initial-sleep Window’ value represents a start value requested for the sleep interval, and the ‘Final-sleep Window’ value represents a stop value requested for the sleep interval. That is, as described above for the sleep interval update algorithm, the sleep interval may be updated within a range from the initial-sleep window value to the final-sleep window value.
2) A Sleep Response (SLP RSP) Message
The sleep response message is a message in response to the sleep request message. The sleep response message may be used to represent whether to approve or deny the state-transition into the sleep state 220 requested by the MSS, or to represent the state-transition into the sleep state 220 according to an unsolicited instruction. A detailed description of when the sleep response message is used as a message for the unsolicited instruction is omitted here but will be provided in more detail below. The sleep response message contains information elements required when the MSS operates in the sleep state 220. Table 2 shows the format of the sleep response message.
TABLE 2SyntaxSizeNotesMOB_SLP-RSP_Mes-sage_Format( ) { Management Message 8 bits Type = 46 Sleep-approved 1 bit0: Sleep-mode request denied1: Sleep-mode requestapproved If (Sleep-approved == 0) {  After-REQ-action 3 bits000: the MSS mayretransmit the SLP-REQmessage at any time001: the MSS shallretransmit the SLP-REQmessage after thetime duration given by theBS in the message010: the MSS shall notretransmit the SLP-REQmessage and wait theSLP-RSP message fromthe BS011:111: Reserved  REQ_Duration 4 bitsTime duration for casewhere After-REQ-actionvalue is 001. } else {  Start-frame 7 bits  Initial-sleep window 6 bits  Final-sleep window10 bits }}
The sleep response message also is a dedicated message transmitted based on the connection ID of an MSS, and the sleep response message includes information elements as shown in Table 2, which will be described hereinafter.
The ‘Management Message Type’ is a type of a message currently being transmitted. For example, when the ‘Management Message Type’ has a value of 46 (Management Message Type=46), it represents the sleep response message. Further, the value of the ‘Sleep-approved’ is expressed by one bit. Therefore, when the ‘Sleep-approved’ has a value of 0, it implies that the request for the transition 220 into the sleep state has been denied. However, when the ‘Sleep-approved’ has a value of 1, the request for the transition into the sleep state has been approved.
3) A Traffic Indication (TRF_IND) Message
The traffic indication message is transmitted to an MSS during the listening interval and represents the existence or absence of packet data to be transmitted from a BS to the MSS. Table 3 shows the format of the traffic indication message.
TABLE 3SyntaxSizeTRF-IND_Message_Format( ) {  Management Message Type = 47 8 bits  Num-positive 8 bits  for (i = 0: i < Num-positive: i++) {    CID16 bits  }}
The traffic indication message is a broadcasting message transmitted according to the broadcasting method, differently from the sleep request message and the sleep response message. The traffic indication message represents if packet data to be received by the MSS awaken from the sleep state 220 exists during the listening interval. The MSS decodes the broadcasted traffic indication message during the listening interval and determines whether to state-transit into the awake state 210 or to continue to stay in the sleep state 220. When the MSS state-transits into the awake state 210, the MSS confirms frame sync.
When the frame sync does not coincide with a frame sequence number expected by the MSS, the MSS can request retransmission of packet data lost in the awake state 210. When the MSS fails to receive the traffic indication message during the listening interval or the traffic indication message received by the MSS does not contain a positive indication, the MSS returns to the sleep state 220. That is, the MSS awaken from the sleep state 220 receives the traffic indication message and state-transit into the awake state 210 only when the received traffic indication message includes a positive indication targeting the MSS itself (i.e., a connection ID of the MSS itself).
Hereinafter, the information elements of the traffic indication message shown in Table 3 will be described.
The ‘Management Message Type’ represents a type of a message currently being transmitted. For example, when the ‘Management Message Type’ has a value of 47 (Management Message Type=47), it represents the traffic indication message. Further, the ‘Num-positive’ includes the number of positive MSSs (i.e., MSSs which will receive packet data) and a connection ID of each of the positive MSSs.
FIG. 3 is a signal flowchart schematically illustrating a process in which an MSS enters a network of a conventional IEEE 802.16e communication system. Referring to FIG. 3, in step 311, after a power-on, the MSS monitors all predetermined frequency bands and detects a pilot channel signal having a largest magnitude (e.g., a pilot channel signal having the largest CINR). Then, the MSS determines the BS transmitted the pilot channel signal having the largest CINR as the serving BS to which the MSS currently belongs. The MSS receives preambles of downlink frames transmitted from the serving BS and acquires system sync with the serving BS.
Thereafter, the MSS acquires downlink sync from BS information contained in messages broadcasted by the BS, which includes a Downlink Channel Descriptor (DCD) message, an Uplink Channel Descriptor (UCD) message, a downlink map (DL-MAP) message, an uplink map (UL-MAP) message, and a mobile neighbor advertisement (MOB-NBR-ADV) message.
In step 313, the MSS transmits a ranging request (RNG-REQ) to the BS, receives a ranging response (RNG-RSP) from the BS in response to the RNG-REQ, and acquires uplink sync with the BS from the RNG-RSP. In step 315, the MSS adjusts frequency and power.
In step 317, the MSS negotiates with the BS about a basic capacity of the MSS. In step 319, the MSS acquires a Traffic Encryption Key (TEK) by performing authentication operation together with the BS. In step 321, the MSS requests the BS to register the MSS and the BS completes registration of the MSS.
In step 323, the MSS performs Internet Protocol (IP) connection with the BS. In step 325, the MSS downloads operational information through the IP in connection with the BS. In step 327, the MSS performs service flow connection with the BS. Here, the service flow refers to a flow in which MAC-SDUs (service data units) are transmitted and received through a connection having a certain QoS. Thereafter, in step 329, the MSS uses the service provided from the BS, and the process ends.
To support a handover in the IEEE 802.16e communication system, the MSS must measure CINRs of pilot channel signals transmitted from neighbor BSs and the BS (i.e., the serving BS) to which the MSS currently belongs. Hereinafter, a process in which the MSS measures CINRs of pilot channel signals transmitted from the serving BS and the neighbor BSs in the IEEE 802.16e communication system will be described with reference to FIG. 4. Herein, for convenience of description, the phrase ‘measure the CINR of the pilot channel signal’ may be expressed by ‘scan or perform a scanning for the CINR of the pilot channel signal’.
FIG. 4 is a signal flow diagram schematically illustrating a process of scanning CINRs of pilot channel signals transmitted from a serving BS and neighbor BSs in a conventional IEEE 802.16e communication system. Referring to FIG. 4, the serving BS 410 transmits a MOB-NBR-ADV message to the MSS 400 in step 411. Additionally, the flow diagram in FIG. 4 is based on an assumption that there are two neighboring BSs (N_Neighbors=2).
The MSS 400 can acquire information on the neighbor BSs from the received MOB-NBR-ADV message. When the MSS wants to scan CINRs of pilot channel signals transmitted from the neighboring BSs, the MSS transmits a Mobile Scanning Interval Allocation Request (MOB-SCN-REQ) message to the serving BS 410 in step 413. Here, interval information of the scanning interval to be scanned by the MSS 400 is included in the MOB-SCN-REQ message by the MSS 400, and in FIG. 4 it is assumed that the scanning interval corresponds to N frames (DURATION=N FRAMES).
The time point at which the MSS 400 transmits the scanning request has no direct relation to the CINR scanning of the pilot channel signal, so detailed description thereof is omitted here.
The serving BS having received the MOB-SCN-REQ message transmits a Mobile Scanning Interval Allocation Response (MOB-SCN-RSP) message to the MSS 400 in step 415. Here, the MOB-SCN-RSP message includes information on a time point at which the MSS 400 starts the scanning and information on duration of the scanning interval. In FIG. 4, it is assumed that the time point at which the MSS 400 starts the scanning is a time point when M frames have passed after the MOB-SCN-RSP message was received (START IN M FRAMES, DURATION=N FRAMES).
After receiving the MOB-SCN-RSP message containing the scanning information, the MSS 400 waits for scanning of CINRs of the pilot channel signals during the M frames in step 417. Then, the MSS scans CINRs of the pilot channel signals during the scanning interval included in the MOB-NBR-ADV message (i.e., during N frames) for the neighboring BSs acquired through reception of the MOB-NBR-ADV message in step 419.
FIG. 5 is a signal flow diagram schematically illustrating a handover process in a conventional IEEE 802.16e communication system. Referring to FIG. 5, the MSS scans CINRs of the pilot channel signals from the neighboring BSs in the process described with reference to FIG. 4 in step 511. When the MSS 500 determines that it is necessary to change the serving BS to which the MSS belongs, that is, when the MSS 500 determines that it is necessary to replace the current serving BS by a new serving BS different from the current serving BS in step 513, the MSS 500 transmits an MSS Handover Request (MOB-MSSHO-REQ) message to the current serving BS 510 in step 515.
In FIG. 5, it is assumed that the MSS 500 has three neighboring BSs including a first BS 520, a second BS 530, and a third BS 540. Here, the MOB-MSSHO-REQ message includes the scanned result of the CINRs of the pilot channel signals.
After receiving the MOB-MSSHO-REQ message transmitted from the MSS 500, the serving BS 510 detects information on a list of neighboring BSs to which the MSS 500 can be handed over from information contained in the received MOB_MSSHO_REQ message in step 517. Here, for the convenience of description, the list of neighboring BSs to which the MSS 500 can be handed over will be referred to as ‘handover-available neighboring BS list’. FIG. 5 is based on an assumption that the handover-available neighboring BS list includes the first BS 520 and the second BS 530. The serving BS 510 transmits a handover notification (HO-notification) message to the neighbor BSs included in the handover-available neighboring BS list, i.e., the first BS 520 and the second BS 530 in steps 519 and 521. Upon receiving the HO-notification message from the serving BS 510, each of the first BS 520 and the second BS 530 transmits a handover notification response (HO-notification-response) message, which is a response message to the HO-notification message, to the serving BS 510 in step 523 and 525. The HO-notification-response message includes a plurality of Information Elements (IEs) including an MSS ID of the MSS 500 intending to handover to a corresponding neighboring BS, a response (ACKnowledgement(ACK)/Negative ACKnowledgment(NACK) indicating if the neighboring BSs can perform the handover in response to the request of the MSS 500, and bandwidth and service level information which each of the neighboring BSs can provide when the MSS 500 is handed over to each of the neighboring BSs.
When the serving BS 510 has received the HO-notification-response messages transmitted from the first neighboring BS 520 and the second neighboring BS 530, the serving BS 510 selects a neighboring BS, which can optimally provide a bandwidth and a service level requested by the MSS 500 when the MSS 500 is handed over, as a target BS to which the MSS 500 will be actually handed over. For example, if the service level required by the MSS 500 is higher than a service level that can be provided by the first neighboring BS 520 and is equal to a service level that can be provided by the second neighboring BS 530, the serving BS 510 will select the second neighboring BS 530 as the target BS to which the MSS 500 will be actually handed over to. The serving BS 510 transmits a handover notification confirmation (HO-notification-confirm) message to the second neighboring BS 530 as a response to the HO-notification-response message in step 527.
The serving BS 510 transmits an MSS handover response (MOB-HO-RSP) message to the MSS 500 as a response to the MOB-MSSHO-REQ message in step 529. The MOB-HO-RSP message contains information on the target BS to which the MSS 500 will be handed over.
Upon receiving the MOB-HO-RSP message, the MSS 500 analyzes the information contained in the MOB-HO-RSP message and selects the target BS to which the MSS 500 will be handed over. After selecting the target BS, the MSS 500 transmits an MSS handover indication (MOB-HO-IND) message to the serving BS 510 as a response to the MOB-HO-RSP message in step 531.
Upon receiving the MOB-HO-IND message, the serving BS 510 recognizes that the MSS 500 will be handed over to the target BS (i.e., the second neighboring BS 530) included in the MOB-HO-IND message, and then releases the present setup link with the MSS 500 in step 533. The MSS 500 performs an initial ranging process with the second neighboring BS 530 in step 535 and performs a network entry process with the second neighboring BS 530 when succeeded in the initial ranging in step 537.
The handover-related operations as described above with reference to FIGS. 4 and 5 are operations performed by the MSS in the awake state. However, when the MSS in the sleep state detects that the MSS itself has reached a cell boundary zone, the MSS state-transitions from the sleep state to the awake state and performs the handover-related operations as described with reference to FIGS. 4 and 5. That is, when the MSS moves from a first cell to a second cell in the sleep state, the MSS cannot restore the connection with a first BS controlling the first cell and performs a network entry process with a second BS controlling the second cell. In performing the network entry process in the current IEEE 802.16e communication system, the MSS transmits an identifier (BS ID) of the previous BS to which the MSS has previously belonged, in order for the new BS to recognize that the MSS is being handed over. Then, the new BS can acquire information of the MSS from the previous BS and perform the handover together with the MSS.
The above description is given on both a method for reducing power consumption of an MSS and a method for handover of an MSS. However, when the method for handover of an MSS is applied to an MSS in the sleep state, an efficiency of the method for reducing power consumption is degraded because the MSS, although it is in sleep state, must perform the handover as described above whenever it shifts between cells. More specifically, because even an MSS having no traffic to transmit or receive must perform the handover whenever it shifts between cells, the effect of reduction of power consumption of the MSS is degraded and message overhead is generated during the handover operation.
Additionally, all MSSs in the sleep state and the awake state perform periodic ranging. However, the periodic ranging of the MSSs in the sleep state cause unnecessary power consumption and generates message overhead.
Further, the current IEEE 802.16e communication system constantly assigns various types of basic radio resources, even to MSSs having no traffic to transmit or receive. Hereinafter, the constantly assigned basic radio resources will be described.
(1) Basic Connection Identifier (basic CID)
The basic connection identifier is used in transmitting a message that is relatively short and must be urgently transmitted (i.e., an urgent control message).
(2) Primary Management CID
The primary management CID is used in transmitting a message that is relatively long and has a relatively lower urgency.
(3) Secondary Management CID
The secondary management CID is used in transmitting a message that has a relatively lower urgency and relates to a standard protocol.
Further, in the IEEE 802.16e communication system, each MSS is assigned an Internet Protocol version 4 (IPv4) address, which is also a limited radio resource. As described above, in the IEEE 802.16e communication system, radio resources as described above, such as the connection identifiers and IPv4 are assigned to even MSSs actually having no transmitted or received traffic. Therefore, there is a necessity for a specific operation scheme of a MAC layer for supporting operations between a BS and an MSS, which can maximize efficiency in using radio resources, while minimizing power consumption of the MSS moving at a high speed.